feat(examples): run the OpenCode example on one GPU with Qwen3.8-27B-FP8 - #756

Resolve the OpenCode example conflicts with the one-GPU recipe (#756):
list the gpu and openrouter recipes together, keep main's key check that
applies only to a recipe that reads SIE_BASE_URL and SIE_API_KEY, and add
the openrouter recipe to its test instead of a second key test.

conformance.py gained the long_tool_call case in #756. The stand-in now
answers it with the whole write_file call, streamed in 4 KiB argument
pieces, so the recipe test expects 11 pass and pins the twelfth request.
The pending real-key results gain a long_tool_call row.

…penRouter upstream (#735)

* fix(server): accept a usage event that restates a finished chat choice

An OpenAI-compatible upstream may end a chat stream with a usage event that repeats the finished choice with an empty delta and the same finish_reason, instead of an empty choices array. OpenRouter documents this form. The remote chat parser refused any event for a finished choice, so every streamed answer from such an upstream failed as an invalid chat response.

The parser now drops a choice on the usage event that restates its finish reason and carries nothing else, and forwards the usage as an OpenAI-form chunk. A restated choice with content, reasoning, tool calls, logprobs, a different finish reason, or without usage is still refused.

* feat(examples): run the OpenCode example on self-hosted SIE with an OpenRouter upstream

Adds a fourth recipe: sie-server on the reader's machine serves zai-org/GLM-5.3-Flash as a remote-backed model through an OpenRouter upstream, and OpenCode talks to the local server. The recipe holds the server's upstreams.yaml and models directory and the OpenCode config. run_gate.sh accepts it as a local-server recipe that needs no SIE key.

A new test starts the repository's sie-server with the recipe pointed at a loopback stand-in that streams the way OpenRouter documents (SSE comment lines, a reasoning field, tool-call deltas, a usage event that restates the finished choice) and runs conformance.py against it. The README records how to run it and leaves the real-key result pending.

* docs(examples): say only the server needs the OpenRouter key

* fix(examples): drop require_parameters from the OpenRouter recipe

Every OpenRouter endpoint of z-ai/glm-5.3-flash lists tools and
tool_choice, and OpenRouter already sends a request with tools only to
providers that support them, so the preference added no guarantee. It
did hold each request to the parameters a provider lists, and the server
adds stream_options to every streamed request, which no endpoint lists.

The stand-in now refuses a require_parameters request with 404 when a
field falls outside every endpoint's published parameter list, and the
test pins the exact fields the server forwards. The README says which
failures answer 502 upstream_error.

* fix(server): log why a remote chat request failed

The single-node remote chat route answered every refused or broken
upstream call with the same fixed 502 (or, after output, the same
in-stream error) and logged nothing but the access line, so a missing
upstream key, a 401, a 402, a 404 and an upstream error event all looked
the same to an operator.

The route now logs the failure's reason at warning level, for example
"the upstream credential is unavailable" or "upstream answered 401".
The reason is the server's own fixed text and repeats nothing the
upstream sent. The caller's answer is unchanged.

An OpenAI-compatible answer that carries an error object in place of the
chat answer, as an upstream sends when the provider behind it fails after
the 200, is now reported as "upstream sent an error instead of a chat
answer" rather than as an invalid chat response, so the log tells it
apart from an answer the parser refused.

* test(examples): pin each OpenRouter request and the stand-in's routing rule

The stand-in now applies require_parameters only to the parameter names
OpenRouter's public model list uses, the LLM parameters its provider
routing docs refer to. stream and stream_options are not among them.
Under that rule the recipe's earlier require_parameters setting would
have excluded none of the model's 33 endpoints for any request the
server sends, so it was not shown to cause the 502s of the first run
with a real key.

The test pins the exact fields and values of each request the
conformance check sends through the server, and checks that a 401, 402,
404 or an error event from the stand-in comes back as a 502 whose reason
the server log names. The fixture gains the 26 parameter names from
OpenRouter's model list.

The README lists what a 502 on this route can mean and the log reason
for each, states what dropping require_parameters changes, and records
that tool_choice_required can fail on an endpoint without "required"
support.

* docs(examples): name the statuses that give 503 on the OpenRouter route

* docs(examples): scope the OpenRouter 502 to upstream failures

* docs(examples): state the OpenRouter 400, 402 and unset-key behavior the server now has

An OpenRouter 400 or 422 now reaches the caller as 400 invalid_request with its own log line, the server warns at startup when OPENROUTER_API_KEY is unset, and the chat route checks calls against the request's tools. The 402 row names the paid model.

* docs(examples): say a successful real-key OpenRouter run is still pending

* docs(examples): name the OpenRouter recipe test beside the fake-engine test

* test(examples): answer the long tool call in the OpenRouter stand-in

conformance.py gained the long_tool_call case in #756. The stand-in now
answers it with the whole write_file call, streamed in 4 KiB argument
pieces, so the recipe test expects 11 pass and pins the twelfth request.
The pending real-key results gain a long_tool_call row.

* docs(examples): give the OpenRouter recipe the caller messages for each upstream failure

Since #744 a remote upstream failure answers the caller with a message
and reason that name its class instead of "upstream generation request
failed". The recipe test now expects those messages for the 401, 402,
404 and error-event cases, and the README table lists each log line
beside the message the caller gets.

---------

Co-authored-by: Krisztian Gajdar <krisztian@superlinked.com>